home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
rbbs_pc
/
msgtos20.zip
/
MSGCFG.DOC
< prev
next >
Wrap
Text File
|
1992-02-11
|
67KB
|
1,915 lines
MSGTOSS Version 2.0
High-Performance FidoNet Mail Processor for RBBS-PC
Copyright(c) 1989-92, Mike Zakharoff & Warren Muldrow
Mike : FidoNet 1:138/154 Rbbsnet 8:918/10
Warren: FidoNet 1:3617/1 Rbbsnet 8:928/1
ALL RIGHTS RESERVED
R E F E R E N C E M A N U A L
for
MSGTOSS.CFG
Written by Mike Zakharoff
MSGTOSS.CFG contains system-related parameters which affect all aspects of
MSGTOSS operation. These entries include such entries as file/paths en-
tries, multi-tasking/LAN related parameters, and other items that affect
MSGTOSS in a global manner.
For description purposes, all entries in the MSGTOSS.CFG are referred to
as "parameters" in this and other MSGTOSS document(s).
DISCLAIMER
----------
The authors make no claims or warranties with respect to the contents or
accuracy of this publication, or the product it describes, including any
warranties of fitness or merchantability for a particular purpose. Any
stated or expressed warranties are in lieu of all obligations or
liability for any damages, whether special, indirect, or consequential,
arising out of or in connection with the use of this publication or
the product it describes. Furthermore, the right is reserved to make any
changes to this publication without obligation to notify any person
of such changes.
MSGTOSS.CFG Reference Manual
L I C E N S E
-------------
MSGTOSS is not a Public Domain program and is not free. MSGTOSS is
copyright(c) 1989,1990,1991,1992 by Mike Zakharoff and Warren Muldrow.
Non-registered users of this program are granted a two week license to
evaluate the program suitability for their requirements. Any usage of
Msgtoss beyond evaluation time period requires registration. Use of non-
registered copies of Msgtoss beyond the original evaluation period is not
wished. You are free to distribute the PUBLICLY AVAILABLE shareware version
of MSGTOSS.
MSGTOSS is SHAREWARE. MSGTOSS was not an easy project, as it took 1000's
of hours to develop and test. The author has written other RBBS utilities
such as MSGRENUM, MAILWAIT, MSGECHO, FIXMSG, all of which were released as
freeware; none of which compares to the complexity of MSGTOSS. Fu-
ture releases of MSGTOSS will depend upon how much support the author re-
ceives. Therefore the author is asking for $25.00 for its use to:
MIKE ZAKHAROFF
18004 22ND ST CT E
SUMNER, WA 98390
Keep in mind that the authors could have easily crippled MSGTOSS with all
sorts of schemes, including disabling the multi-tasking/network support,
requiring a password, annoying "not-registered" lines appended to the tear
line, beg screens, long delays, and other things to pester you to support
the authors. If I were to figure out the amount of hours it took to devel-
op and test this program, it would easily run into 10,000 hours of personal
time that really can't be assigned any value. This was a service to the
RBBS-PC community, and its development will set the stage for RBBS-PC's fu-
ture in the Fidonet comminity. Cards and letters always welcome!
Registered users will receive a personal registration code (See REGCODE in
MSGCFG.DOC), and as much personal support as possible. Non-supporters
will basically be doomed to slither in their own guilt for all eternity.
WARRANTIES
----------
MSGTOSS is guaranteed only to occupy space on your hard drive. Therefore
the use of MSGTOSS is solely at your own risk! MSGTOSS had been beta
tested extensively to eliminate bugs, however due to the limitless pos-
sibilities of system configurations, no warranty is possible. Also,
there are no guarantees that the author will upgrade MSGTOSS.
TRADEMARKS
----------
The following products are mentioned in this documentation:
Binkleyterm,Desqview,Frontdoor,Lharc,Makearc,Ommm,Qmail,RBBS-PC & Spaz
Page - 2
MSGTOSS.CFG Reference Manual
TABLE OF CONTENTS
-----------------
Page
Network Address Parameters................................ 5
ZONETYPE----> Amount of zone tightness ................ 5
DOMAIN------> Location of Nodelists ................... 5
NODE--------> Full 5d Zone:Net/Node address ........... 5
POINTNET----> Point net address for NODE .............. 7
REMAP-------> Users to be remapped .................... 7
Mail and File Forwarding authorizations................... 8
MAILFROM----> RouteMail authorizations ................ 8
MAILTO------> RouteMail authorizations ................ 8
FILEFROM----> RouteFile authorizations ................ 8
FILETO------> RouteFile authorizations ................ 8
KILLNULL----> Kill null messages (Y/N) ................ 9
Maximum Messages Exported during /FEED ................... 10
PACKERCMD---> Cmd to pack up mail for HUBS ............ 10
Sysop Names Parameters.................................... 11
SYSALIAS----> Secret name of sysop .................... 11
SYSNAME-----> Common names of sysop ................... 11
Packet Unarchiving & SPAZ Information..................... 13
SPAZ INFO Text on how to use SPAZ ................ 13
PKTWILD-----> Fido packet extensions .................. 13
Miscellaneous directories................................. 14
FILES-------> Where MSGTOSS looks for mail/files ...... 14
OUTBOUND----> Where *.OUT files are built ............. 14
WORKDIR-----> RAM disk directory for faster I/O ....... 15
LOGDIR------> Where MSGTOSS.LOG is written ............ 15
Two important RBBS message bases.......................... 16
MESSAGES----> Main RBBS message base .................. 16
BLANKMSG----> Blank message base used for auto-repair . 16
RBBS message base parameters.............................. 17
RBBS-MAX----> RBBS maximum messages setting ........... 17
ELASTIC-----> Support ELASTIC message bases ........... 17
MSGMULT-----> Method to calculate max-messages ........ 17
KILLOVER----> Ignore RBBS messages over this size ..... 18
NETBIOS, DESQVIEW, PC-NET & 10-NET........................ 19
LOCKTYPE----> Method of file locking .................. 19
LOCKWAIT----> Seconds to wait after un-locking ........ 19
LOCKTIME----> Max seconds before forcing un-lock ...... 19
Page - 3
MSGTOSS.CFG Reference Manual
TABLE OF CONTENTS (Cont.)
-----------------
Page
RBBS purging related parameters........................... 21
MAINT%LO----> Min % capacity when purge is required ... 21
MAINT%HI----> Max % capacity before purge is required . 21
DAYSTOSYS---> Sysop messages age before auto-kill ..... 22
DAYSFRSYS---> Sysop messages age before auto-kill ..... 22
DELREADSYS--> Sysop auto-kill message if read ......... 22
DAYSTOUSR---> User messages age before auto-kill ..... 22
DAYSFRUSR---> User messages age before auto-kill ..... 22
DELREADUSR--> User auto-kill message is read ......... 22
YEAR--------> Current calander year ................... 22
FIXMSGCMD---> Cmd to repair corrupt message bases ..... 23
Duplicate checking related stuff.......................... 24
DUPFILE-----> Database of EID codes ................... 24
MAXAREAS----> Reserves spaces in EID database ......... 24
DUPSIZE-----> Number of messages to dup check ......... 24
Wait for users to go off-line............................. 25
CONFWAIT----> Minutes to wait ......................... 25
Words used for message "capturing"........................ 26
CAPTURE-----> Colorful metaphors to capture ........... 26
Strip lines beginning with "text"......................... 28
SECL--------> Text to strip lines ..................... 28
Miscellaneous Stuff....................................... 29
UTIL1-------> File to place UTIL1CMD data ............. 29
UTIL1CMD----> Misc utility commands ................... 29
UTIL2-------> File to place UTIL2CMD data ............. 29
UTIL2CMD----> Misc utility commands ................... 29
REGCODE-----> Registration code ....................... 29
INDEX (See MSGIDX.DOC).................................... <-
Page - 4
MSGTOSS.CFG Reference Manual
Network Address Parameters
--------------------------
ZONETYPE - Either "1", "2" or "3".
Example:
ZONETYPE---->2
1) Common UNKNOWN, MSGCAPTURE, NETMAIL and ROUTETHRU areas
for all zones and domains.
2) Separate UNKNOWN, MSGCAPTURE, NETMAIL and ROUTETHRU
areas for each unique domain. All zones within a do-
main share the same areas.
3) Separate UNKNOWN, MSGCAPTURE, NETMAIL and ROUTETHRU ar-
eas for all zones/domains.
----------------------------------------------------------------------
DOMAIN - Identifies all of the domains to which you belong, the de-
fault zone number for that domain, and the directory and
file name of the St. Louis format (raw, uncompiled) node
list(s) for that domain. If a file extension is not spec-
ified, MsgToss will look for the newest node list with
that name when it compiles the node list data (see the
/NLST command line switch). The domain statement and a
compiled nodelist is required if you use more than a sin-
gle domain or zone.
Example:
DOMAIN------>fidonet.org 1 C:\MAIL\NODELIST\nodelist
DOMAIN------>rbbs-net.org 8 C:\MAIL\NODELIST\rbbslist
NOTE: The /NLST switch calls the MSGNLST.EXE program,
which creates a MSGTOSS (only) binary nodelist
called MSGTOSS.NOD in the default directory.
-----------------------------------------------------------------------
NODE - Full "5 dimensional" address of all FidoNet compatible
AKA's.
[zone]:[net]/[node].[point]@[domain]
^ ^ ^ ^
These are required!
Example:
NODE-------->1:343/36.0@fidonet
NODE-------->8:918/0.0@rbbs-net
NODE-------->30:333/66.0@eggnet
MSGTOSS expects a ":/.@" to be in this entry. The "36.0"
indicates that you are NOT a point of another... if you
are, then enter your point number as "36.2" if you are the
Page - 5
MSGTOSS.CFG Reference Manual
second point of someone else... Normally, this would just
be "36.0".
NOTE: The ZONE of the FIRST node listed is the DEFAULT
ZONE!
NOTE: The order of the NODE--------> entries must coincide
with the "NODE:x" entries in your MSGTOSS.BBS file
(very important!)
NOTE: You can have up to 10 NET/NODES
NOTE: The @domain must match to one of your DOMAIN------>
statements!!
NOTE: Your FIRST node entry should be your DEFAULT domain
NOTE: If you have multiple NODE--------> entries within
the same domain (like 1:343/1, 1:343/0, 1:343/2)
then you MUST list the node entry which you want to
appear in your * Origin: line FIRST.
Example: You are a HUB and you are 1:343/0,1 & 2... You
DON'T want 1:343/0 to appear in the * Origin:
line, so you would enter the following:
NODE-------->1:343/1.0@fidonet (* Origin line)
NODE-------->1:343/2.0@fidonet
NODE-------->1:343/0.0@fidonet
****************************** IMPORTANT!! ****************************
* The NODE--------> entries MUST coincide with the "NODE:x" entries *
* in your MSGTOSS.BBS file. For instance, if your FIRST NODE entry *
* is: *
* *
* NODE------->1:343/36.0@fidonet *
* *
* Then you must have a NODE:1 ("1" meaning your FIRST NODE--------> *
* entry) which informs MSGTOSS that these conferences (MSGTOSS.BBS) *
* are associated with this NODE-------> entry. *
* *
* NOTE: Failure to set these correct will screw up the * Origin: *
* lines during an export! *
* *
* NOTE: Once you configure a NODE-------> entry to a corresponding *
* NODE:x entry (MSGTOSS.BBS) you shouldn't change the ORDER *
* of the NODE--------> entries unless you simultaneously *
* change the order of the NODE:x entries. *
* *
* Remember, remember, remember... These two items (NODE-------> & *
* NODE:x) are linked and MUST be configured properly. *
* *
* Confused? See the sample MSGTOSS.CFG and MSGTOSS.BBS files and *
* notice how NODE:1 corresponds to NODE-------->1:343/36.0@fidonet *
* and NODE:2 corresponds to NODE-------->8:918/10.0@rbbs-net. *
* *
Page - 6
MSGTOSS.CFG Reference Manual
* Also see documentation on the MSGTOSS.BBS NODE:x entry. *
* *
***********************************************************************
-----------------------------------------------------------------------
POINTNET - Your private "point" network. MSGTOSS will strip outgoing
point addresses before being transmitted to main host.
Will add a "FMPT x" to all mail from points. Will re-ad-
dress NETMAIL addressed to main system to the point IAW
the "TOPT x" entry that should be in the incoming NETMAIL
point mail. Each defined NODE address can have a differ-
ent point network. The POINTNET line must follow the NODE
address to which it belongs
NOTE: The order of this entry must coincide with a
NODE--------> entry. For instance:
NODE-------->1:343/36.0@fidonet
POINTNET---->30174
Because 30174 follows 1:343/36, therefore it MUST be
a point address of it. If you add a POINTNET
entry before a NODE entry, MSGTOSS will complain
about it.
-----------------------------------------------------------------------
REMAP - Remaps mail to POINT addresses when a message does NOT
contain a valid "TOPT x" entry. The REMAP lines must
follow the POINTNET line to which they belong.
------>[Point Number](space)[First Last]
Example:
NODE------->1:343/36.0@fidonet
POINTNET--->30174
REMAP------>1 Rich Englich
Any NETMAIL that is received for "Rich Englich" will be
re-mapped to address 1:30174/1.
NOTE: The order of this entry must coincide with a
POINTNET---> entry. For instance:
Because 30174 follows 1:343/36, therefore it MUST be
a pointnet address of it. Since REMAP 1 follows
POINTNET 30174, then 1:30174/1 must be Rich Englich.
If you add a REMAP entry before a POINTNET entry,
MSGTOSS will complain about it.
-----------------------------------------------------------------------
Page - 7
MSGTOSS.CFG Reference Manual
Mail and File Forwarding authorizations
---------------------------------------
MAILFROM - Nodes FROM which mail will be routed
MAILTO - Nodes TO which mail will be routed
FILEFROM - Nodes FROM which files will be routed
FILETO - Nodes TO which files will be routed
The MAILFROM and MAILTO options control routing of net
mail. Mail addressed to another system which is received
from a node listed (or not excluded) in the MAILFROM line
will be forwarded. Also mail addressed to any system
listed (or not excluded) in the MAILTO line will be for-
warded.
Extreme Example:
MAILFROM---->1:*/* 8:*/*
This means that MSGTOSS will route (send) mail anywhere,
regardless of where the destination is, as long as the
originator (MAILFROM) resides in Zone 1 or Zone 8, any
Net/Node. This is NOT a good idea (unless you have an ar-
ea called ROUTETHRU).
MAILTO------>1:*/* 8:*/*
This means that MSGTOSS will route (send) mail anywhere,
regardless of where the destination is, regardless of who
sent it, as long as the destination (MAILTO) resides in
Zone 1 or Zone 8, any Net/Node. This is also NOT a good
idea (unless you have an area called ROUTETHRU).
Confused? Consider this:
MAILFROM---->1:343/-5 -10 *
This means that MSGTOSS will route (send) mail anywhere,
regardless of where the destination is, as long as the
originator (MAILFROM) resides in Zone 1, net 343, except
for 1:343/5 and 1:343/10 (looks like they abused routing
privileges and were locked out).
NOTE: Note that the '*' at the end of the line means (in
this case) "all the rest".
Consider:
MAILTO------>1:343/* 8:918/*
This means that MSGTOSS will route mail from anyone, as
long as the destination is any node within Zone 1, net 343
or Zone 8, net 918.
Zone:Net/Node Syntax:
Page - 8
MSGTOSS.CFG Reference Manual
'*' is a wild card for "all" or "all the rest"
'-' means to exclude.
Realtime example:
1:343/* 918/1 666/-1 -45 -36 -66 *
Means zone 1, anyone in NET343, 918/1 and anyone in NET666
except nodes 1,45,36, & 66
REMEMBER! Don't confuse "." with "/".... "1:343.*" is
not the same as "1:343/*"!
The FILETO and FILEFROM lines work exactly the same as
MAILFROM and MAILTO, but are used for messages with the
"file attach" flag set. The first FILES statement in your
MSGTOSS.CFG will be used to rebuild the path to the file
named in the subject line of the message so your mail
packer will be able to find the file to be sent.
If the above authorization fails, then the "HOLD" bit is
set on the routed message.
Note that yet another layer of security exists where is
you use the special area called "ROUTETHRU", then ALL
routed mail (regardless) will be sent there and the above
authorization scheme still applies....
Example:
You set MAILFROM, TO FILEFROM,TO to simply.. "*:/*", which
means ALL authorized, for ALL zones, for ALL nets..
If you have an area called ROUTETHRU, then everything not
addressed to your system will go there.. As long as you
DON'T scan the area (normally), you can simply "move" the
message into a NETMAIL area, and it (poof) becomes active
(and authorized).
-----------------------------------------------------------------------
KILLNULL - Kill null messages (Y/N). If this parameter set to 'Y',
MSGTOSS will kill null messages that don't contain text
within its body. These types of messages are usually gen-
erated by file-attach type mailers, used to send mail or
files. MSGTOSS will (as it kills a null message) log its
occurace into a file called MSGTOSS.NUL, which contains
the date, packet, message number, AREA (if present), and
the message header for analysis. MSGTOSS.NUL should be
viewed on occasion.
Example:
KILLNULL---->Y
-----------------------------------------------------------------------
Page - 9
MSGTOSS.CFG Reference Manual
Maximum Messages Exported during /FEED (/FMAX:xxx)
--------------------------------------
PACKERCMD - For HUBS, when doing a /FEED, MSGTOSS will either exit
processing or SHELL out to a packer when /FMAX:xxx
messages have been exported. For instance:
Example:
PACKERCMD--->QMAIL -PACK --or--
PACKERCMD--->OMMM --or--
PACKERCMD--->MAKEARC And "/FMAX:1000" as a switch:
MSGTOSS will, after exporting 1000 messages (in any combi-
nation to any set of nodes), and done with the current PKT
file, close ALL *.OUT files, and SHELL out to PACKERCMD.
When done, will return back, re-open *.OUT files, and con-
tinue on.
However, this requires GOBS of memory, as you all know how
big MSGTOSS is. It seems to work fine with 570K and OMMM
1.52.
Here is a memory saving (but slower) alternate:
Make PACKERCMD---> equal to "" (blank) and use the
/FMAX:xxx switch. MSGTOSS will then gracefully exit,
closing all *.OUT files, mailwaiting, etc. You can then
execute your packer. Then check existence of *.PKT files,
and if present re-execute MSGTOSS.
For instance:
:DOIT
MSGTOSS /TOSS/FEED/FMAX:1000 (PACKERCMD----> = "")
QMAIL -PACK
If exist F:\FILES\*.PKT Goto DOIT
Looping endlessly till all *.PKTS are gone, but is slight-
ly slower.
Recommended to use a SMALL packer (like Ommm 1.52 or Make-
ARC) vice QMAIL -PACK, as they take up alot less overhead
(memory). But you can try it.
NOTE: If you DON'T want MSGTOSS to SHELL, then make
PACKERCMD---> blank! Otherwise, MSGTOSS will simply
shell out. Even if you run out of memory, MSGTOSS
should recover gracefully, as it will simply re-open
the *.OUT files for append.
NOTE: The PACKERCMD----> is likely to go away in the
future when MSGTOSS gets its own packer.
-----------------------------------------------------------------------
Page - 10
MSGTOSS.CFG Reference Manual
Sysop Names Parameters
----------------------
SYSALIAS - The SYSALIAS parameter tells MSGTOSS which user name is
considered the SYSOP. This should be the same name as was
entered in CONFIG for the secret remote logon, and for
LOCAL logon (ESC switch). Any messages that match those
as specified by the various SYSNAME(s) will cause the
mailwaiting bit for the SYSALIAS user to be set, and cause
the TO: field to be changed to the text 'SYSOP', if
'SYSOP' is not already part of the TO: field.
NOTE: MSGTOSS requires that the SYSALIAS exist in all of
the conferences, or a non-fatal error message is
displayed, irritating you until you add it.
-----------------------------------------------------------------------
SYSNAME - This parameter controls what messages are considered the
SYSOP. This is used during the EXPORTING, PURGING, and
MAILWAITING phases of the MSGTOSS. MSGTOSS will set the
SYSOP's mailwaiting bit ONLY if the message matches the
below criteria, and will be exempt from purging as well
until killed.
The FIRST CHARACTER must be either a '!' or a '=', nothing
else is allowed. The '!' means CONTAINS and the '=' means
EXACT.
!SYSOP keep messages that contain the string 'SYSOP' (Not
recommended, as every message to 'JOE SYSOP' will set the
mailwaiting bit for the SYSALIAS user (sysop).
=SYSOP will match on messages that ONLY have 'SYSOP' in
TO/FROM, will set the mailwaiting bits, and be exempt from
purging until either killed by the sysop, or DAYS(s)
parameters apply.
!LASTNAME incase a message 'MIKE ZAKHAROFF @ 343/36'
!SYSOP @343/36 is also recommended or just '!SYSOP @'
Read! --> NOTE: During an EXPORT from an RBBS message base, MSGTOSS
use the FIRST "SYSNAME" entry and use that as the
common name for all messages that originated "FROM"
the sysop. Basically, this means to make your FIRST
entry your REAL name, like:
SYSNAME---->=MIKE ZAKHAROFF
NOTE: During the MAILWAITING processing, MSGTOSS will
convert messages addressed to your SYSNAMES to
'SYSOP', if SYSOP is not already part of the 'TO:'
name, and set the mailwaiting bit for the user you
entered under the SYSALIAS parameter.
Example: A message arrives to 'MIKE ZAKHAROFF'.
Because a SYSNAME is '=MIKE ZAKHAROFF' that message
Page - 11
MSGTOSS.CFG Reference Manual
will be converted to 'SYSOP' in the TO:Field.
Example:A message arrives to 'JOE SYSOP' and
'=SYSOP' is only entered as a SYSNAME. That message
will be treated as if it is another junk message,
and MSGTOSS will purge it whenever it thinks it need
to and will NOT set the sysops mailwaiting bit.
NOTE: ANY message addressed to your SYSNAMES(s) will
cause the mailwaiting bit to be set for the user as
specified by your SYSALIAS!
NOTE: You can have up to 10 SYSNAME(s)
-----------------------------------------------------------------------
Page - 12
MSGTOSS.CFG Reference Manual
Packet Unarchiving & SPAZ Information
-------------------------------------
SPAZ INFO - Command to issue to unarchive mail packets. Recommended
to use only SPAZ.COM, because it can handle ZIP, LHARC,
ARC etc.
SPAZ -F C:\MAIL\FILES C:\MAIL\FILES\
------------- ----------------------------
Incoming Mail Where PKTS go for processing
NOTE!! --> Where trailing back-slashes are!
NOTE: MSGTOSS looks in the directory(s) specified by the
FILES-------> parameter(s) for PKTs. Therefore, the
"C:\MAIL\FILES\" SHOULD match the FILES-----> entry.
NOTE: Place the SPAZ command in your batch file PRIOR to
executing MSGTOSS. Here is an example...
:RECMAIL
SPAZ -F -O C:\MAIL\FILES C:\MAIL\FILES\
If Exist C:\MAIL\FILES\*.pkt Goto TOSSIT
If Exist C:\MAIL\FILES\*.?ut Goto TOSSIT
Goto START
:TOSSIT
Msgtoss /TOSS/PREP/FIXC/NSTOP
If Exist Msgclean.bat Call Msgclean.bat
Goto START
-----------------------------------------------------------------------
PKTWILD - Wildcards of what extentions FIDO Packets can be. This is
useful if you do creative re-naming of *.PKT(s) and you
want MSGTOSS to ONLY recognize *.PKT that have an exten-
tion like maybe "*.ZAK" <grin>. So you just change this
parameter to "*.ZAK" and MSGTOSS will ignore other exist-
ing *.PKT files.
Example:
PKTWILD----->*.PKT *.?UT
-----------------------------------------------------------------------
Page - 13
MSGTOSS.CFG Reference Manual
Miscellaneous directories
-------------------------
FILES - Directory INCOMING mail and files go to FIRST. You can
have up to 10 "FILES------>" entries. MSGTOSS will no
longer look in the default directory for PKTS. Example:
FILES------->C:\FILES\
FILES------->C:\MAIL\FILES\
NOTE: The FIRST entry is considered your default FILES en-
try, and should be the same directory as where your
mailer sends files. This is important only for file
routing services, as MSGTOSS (when attempting to
route files) will LOOK for files in this directory.
MSGTOSS will look in all of your FILES-------> entries for
*.PKT files, as defined in your PKTWILD-----> entries. If
you you don't route files, then all that is important is
that this directory contains these packets.
-----------------------------------------------------------------------
OUTBOUND - The MAIN outbound directory of your default zone (The ZONE
that is present in the FIRST "NODE----->" entry.
Example: OUTBOUND---->C:\BT\OUT
NOTE: MSGTOSS uses the Binkley standard regarding the out-
bound directories for each zone. Example:
C:\BT\OUT.001\ = Zone 1 directory
C:\BT\OUT.008\ = Zone 8 directory
NOTE: If default zone is "1" then....
C:\BT\OUT\ = Zone 1 directory
C:\BT\OUT.008\ = Zone 8 directory
NOTE: If the zone number is greater than 9, then you must
use the HEX value of the zone. For instance, zone
15 would be represented as C:\BT\OUT.00F because "F"
is HEX 15. Don't worry too much about this, as
MSGTOSS will look for the presence of this directory
(during a /TEST) and complain that
C:\BT\OUT.00F does not exist, prompting you to cre-
ate it.
NOTE: MSGTOSS will check for the presence of these for
EACH UNIQUE zone entered in your "NODES------>" en-
tries.
READ! ---> However, if you place [DOMAIN] as part of this parameter,
MSGTOSS will "dynamically" replace the outbound DOMAIN and
use that for the outbound directory. Example:
C:\BT\[DOMAIN]\
Page - 14
MSGTOSS.CFG Reference Manual
If the outbound domain is "fidonet", MSGTOSS will create
the outbound *.OUT file in a directory called
"C:\BT\FIDONET\", the same way that Binkleyterm 2.4+ uses.
The same rule regarding ".001", ".008" extentions also ap-
ply to this.
NOTE: For file-attach systems such as FrontDoor, etc. that
don't use the Binkley standard, you will need a con-
verter utility such as "Makearc" that will archive
the *.OUT files that MSGTOSS creates and create a
file-attach message. This has been tested and works
fine. Makearc is available on most BBS systems.
However, you will still need to create the Binkley
standard directory structure to make MSGTOSS work
properly (sorry).
-----------------------------------------------------------------------
WORKDIR - RAM Disk (recommended) where MSGTOSS will COPY the current
message base being PURGED. Will check for available space
first. Not enough space will cause default directory to
be used. Need to specify the "/WDIR" switch to activate.
Example: WORKDIR----->F:\TEMP\
Where F:\TEMP\ is hopefully (but not necessarily) a RAM
disk.
NOTE: This is also used for copying the MSGTOSS.EID data-
base for doing duplicate file checking (CDUP:1 key-
word) and for building some other temporary files.
Even if you have a real SMALL RAM disk, still use
the /WDIR, as some of MSGTOSS(s) disk-intensive
tasks use small files.
If not enough space is available, MSGTOSS will use
the default disk (where MSGTOSS is executed).
When using the /LOCK switch, MSGTOSS will NOT copy
the message base being purged to the RAM disk.
-----------------------------------------------------------------------
LOGDIR - Where MSGTOSS will write its MSGTOSS.LOG & MSGTOSS.ERR
files. Blank will end up in default directory.
Example:
LOGDIR------>C:\MSGTOSS\
-----------------------------------------------------------------------
Page - 15
MSGTOSS.CFG Reference Manual
Two important RBBS message bases
--------------------------------
MESSAGES - Path/FileName of Main RBBS Message Base. This is used for
the /WAITxx and /LOCK related switches. MSGTOSS needs to
know what directory to write the NETBIOS file "IBMFILES".
For /WAIT, MSGTOSS will monitor the "node" records until
all users are off-line.
Example:
MESSAGES---->C:\RBBS\MESSAGES
-- or --
MESSAGES---->C:\RBBS\MAINM.DEF
In addition, when using the "/MUSER:xx" switch (see docs)
MSGTOSS uses this information to determine which message
base (the main one) to which to modify the nodes records
when MSGTOSS becomes an active "user" on-line.
NOTE: See MSGSWI.DOC for more information on /MUSER:x
MSGTOSS also uses the "user count" field of the main mess-
age base to determine how much memory is required during
purging and mailwaiting operations.
-----------------------------------------------------------------------
BLANKMSG - A "model" message base (un-corrupt, small) that will be
used with the "/FIXC" command line. If FIXMSG fails twice
then the message base entered here will be copied over the
original (corrupt) message base. The corrupt message base
will be renamed *.BAD. This insures that MSGTOSS will
never abort due to a corrupt message base (which it
doesn't tolerate). This occurring will be entered into
the MSGTOSS.LOG file.
Example:
BLANKMSG---->C:\RBBS\BLANKM.DEF
-----------------------------------------------------------------------
Page - 16
MSGTOSS.CFG Reference Manual
RBBS message base parameters
----------------------------
RBBS-MAX - Reflects the current RBBS-PC maximum messages. The
maximum of 999 may soon change to 9999, so this is
why the RBBS-MAX----> parameter is present in the
MSGTOSS.CFG file. The default entry is 999, which
reflects the current RBBS-PC maximum. In the event the
maximum is raised (future releases of RBBS-PC) the MSGTOSS
RBBS-MAX---> parameter will have to be adjusted.
Example:
RBBS-MAX---->999
NOTE: Some clever RBBS-PC programmers have been able to
make code changes to RBBS-PC to increase the
MAX-MESSAGES to over 2000, if you do this, then also
increase RBBS-MAX to that value.
-----------------------------------------------------------------------
ELASTIC - Either "YES" or "NO". This is designed to support the new
"elastic message bases" of RBBS-PC. What this actually
does is tell MSGTOSS to make the "maximum messages" value
that is present in the message base "checkpoint record" to
be the value of the "RBBS-MAX--->" parameter, no matter
what MSGTOSS calculates it to be normally.
Example:
ELASTIC----->NO
NOTE: You can still use the "/PREP" switch, even
though you set ELASTIC to "YES". MSGTOSS will
still CHOP the message bases back down to the
"RECS:xxxx" values set in the MSGTOSS.BBS file.
NOTE: If you set ELASTIC-----> to "YES" it is recommended
that you set MAINT%LO----> and MAINT%HI----> to both
100(%).
-----------------------------------------------------------------------
MSGMULT - What scheme MSGTOSS is going to use when setting the "Max
messages" of an RBBS conference. Setting to blank or "5"
will use regular RBBS standards. Valid entries are 2-5.
Example:
MSGMULT----->5
During the normal operation of MSGTOSS (purging,
expanding, setting mailwaiting bits, etc.) MSGTOSS is
constantly resetting the 'Max Messages' value entered in
the message bases 'Checkpoint Record'. Normally, you set
this value via CONFIG, but MSGTOSS will change it whenever
it requires. RBBS assumes that the 'Max Messages' value
Page - 17
MSGTOSS.CFG Reference Manual
is set APPROXIMATELY to "TOTAL.MESSAGE.RECORDS / 5".
Message records = 1000 - Max Messages = 200 (1000/5)
Message records = 2000 - Max Messages = 400 (2000/5)
This is normally not a problem, but with the introduction
of the SECL--------> entries it is possible for MSGTOSS to
import more messages in a given message base than the
default 'Max Messages' value. Basically this means
that even though there is PLENTY of room for a newly en-
tered message (by a user), if the 'Max Messages' entry
exceeds the number of messages, the user will be pres-
ented with "Not enough room for new messages, try again
tomorrow".
This has been kludged with MSGMULT-----> parameter, where
you can tell MSGTOSS what multiplier to use (default is
5) while setting the 'Max Messages' value. The multi-
plier can be anywhere between 2 and 5.
MSGMULT:5 Records = 1000 - Max Messages = 200 (1000/5)
MSGMULT:4 Records = 1000 - Max Messages = 250 (1000/4)
MSGMULT:3 Records = 1000 - Max Messages = 333 (1000/3)
MSGMULT:2 Records = 1000 - Max Messages = 500 (1000/2)
Basically, leave it at 5 unless you have problems.
-----------------------------------------------------------------------
KILLOVER - Prevent TOSSING (ignore) of any message over this size.
Example:
KILLOVER---->32000
When tossing to *M.DEF files, MSGTOSS will ignore messages
over this size. If you want all messages imported, set to
32000. This only applies to *M.DEF and not a Fido (*.MSG)
area.
-----------------------------------------------------------------------
Page - 18
MSGTOSS.CFG Reference Manual
NETBIOS, DESQVIEW, PC-NET & 10-NET record locking (/LOCK)
-------------------------------------------------
LOCKTYPE - Either "NETBIOS", "DESQVIEW", "PC-NET", "10-NET" or "".
This directs which type of file/record-locking procedure
is used when used in a multi-user environment. To acti-
vate this feature, specify "/LOCK" on the MSGTOSS command
line. Allows tossing to M.DEFs while users are on-line.
Example:
LOCKTYPE---->NETBIOS
MSGTOSS will attempt to detect the presence of NETBIOS
and/or DESQVIEW, but does not attempt to detect PC-NET or
10-NET. If either of these are specified, MSGTOSS will
assume their presence and use their file/record locking
procedures.
If using NETBIOS, then SHARE.EXE (or equivalent) must be
loaded. Most Local Area Networks (LAN) load SHARE as part
of their initialization procedure.
-----------------------------------------------------------------------
LOCKWAIT - How many seconds MSGTOSS is to wait AFTER it unlocks a
message or user base, to allow other nodes a chance to
lock the message and enter messages/what ever. Basically
MSGTOSS is so fast that after it releases a message base
after tossing it will immediately re-lock it to continue
tossing. This is designed to slow it down a tad. An en-
try of "0" will cause no delay, and entry of ".1" will
tell MSGTOSS to wait 1/10 th of a second after un-locking.
Example:
LOCKWAIT---->.1
NOTE: If you run LOTS of nodes, then you may want to set
this higher as the number of nodes are increased.
Each increment will slow down MSGTOSS progressively.
If you run 20 nodes, and two people are writing mes-
sages, and you set LOCKWAIT---->0, then MSGTOSS will
probably not relinquish control of the message bases
to allow these users to save their messages.
-----------------------------------------------------------------------
LOCKTIME - How many seconds MSGTOSS is allowed to keep the message
based locked for any period of time. If locked for a time
exceeding this value, MSGTOSS unlock the message base,
wait for LOCKWAIT seconds, re-load checkpoint data, and
then continue.
Example:
LOCKTIME---->5
Page - 19
MSGTOSS.CFG Reference Manual
Means MSGTOSS can only lock the message base for a MAX of
5 seconds. Because of the smart purging techniques
MSGTOSS uses, sometimes a message base will be purging for
a long time. This will insure that a user will only have
to wait a MAX of 5 seconds if trying to save a message
while MSGTOSS is working in the background.
-----------------------------------------------------------------------
Page - 20
MSGTOSS.CFG Reference Manual
RBBS purging related parameters (/PREP)
-------------------------------
MAINT%LO - When a purge is required, what % capacity to purge to.
MAINT%HI - What is the MAXIMUM % capacity before a purge is required.
If using the /PREP (pre-purging) switch, MSGTOSS will es-
timate how many message base records are required to be
purged to accommodate the new in-coming messages. MSGTOSS
will (whenever a purge is called) make sure the message
base is around MAINT%LO full after the message bases are
tossed. Therefore, if you use /PREP and you have set the
following:
MAINT%LO---->85
MAINT%HI---->95
And RECS:1000 is set for the message base (via
MSGTOSS.BBS) then you can expect that 850 records will
contain actual messages, with 150 records of slack (empty
records) to accommodate new messages entered by users.
Also, whenever a /SIZE (chop message bases) operation is
called, MSGTOSS will purge the message bases so that the
number of records are MAINT%HI (%) of the value of the
"RECS:xxxx" value in the MSGTOSS.BBS file for that confer-
ence.
NOTE: These two parameters control the purging activity of
MSGTOSS. MSGTOSS will automatically maintain the
percent capacity of all messages bases somewhere BE-
TWEEN these two values. Make sure MAINT%HI is a
larger value of MAINT%LO, and that they do not ex-
ceed a value of 100 each.
Its desirable to have some distance between these two val-
ues, like 95 & 85, as if you try to place them too close,
then MSGTOSS will call a purge excessively, even though
few messages have been received.
For instance... You receive a mere 2 messages in a con-
ference, and MAINT%() is set to 94 & 95. MSGTOSS will
probably have to do a purge on the message base. However,
if you wisely set these to 85 & 95, then theres probably
ALREADY 10 % free records avail to accommodate those 2
messages, so MSGTOSS will simply append them to the end.
As long as the append doesn't violate the MAINT%HI value,
then a purge is not required.
If you have LARGE message bases, then the ideal setting
for is probably 70% and 95%. This way, whenever the mes-
sage bases exceeded 95% capacity, MSGTOSS will purge to
70% capacity, and another purge will probably not be re-
quired for multiple mail sessions because of the 25%
slack.
Page - 21
MSGTOSS.CFG Reference Manual
-----------------------------------------------------------------------
DAYSTOSYS - Applies ONLY to messages TO the SYSOP: How many days old
the message is before it will be KILLED automatically.
Example:
DAYSTOSYS--->60
-----------------------------------------------------------------------
DAYSFRSYS - Applies ONLY to messages FROM the SYSOP: How many days old
the message is before it will be KILLED automatically
Example:
DAYSFRSYS--->60
-----------------------------------------------------------------------
DELREADSYS - Applies ONLY to messages TO the SYSOP: If the message has
been read by the SYSOP, then automatically KILL it,
regardless of the setting of DAYSTOSYS parameter. If
unread, will remain until the DAYSTOSYS parameter applies.
(YES or NO).
Example:
DELREADSYS-->NO
-----------------------------------------------------------------------
DAYSTOUSR - Applies ONLY to messages TO the USERS: How many days old
the message is before it will be KILLED automatically.
Example:
DAYSTOUSR--->30
-----------------------------------------------------------------------
DAYSFRUSR - Applies ONLY to messages FROM the USERS: How many days old
the message is before it will be KILLED automatically
Example:
DAYSFRUSR--->30
-----------------------------------------------------------------------
DELREADUSR - Applies ONLY to messages TO the USERS: If the message has
been read by the USER, then automatically KILL it,
regardless of the setting of DAYSTOUSRS parameter. If
unread, will remain until the DAYSTOUSR parameter applies.
(YES or NO).
Example:
DELREADUSR-->NO
-----------------------------------------------------------------------
YEAR - MSGTOSS depends on the SYSTEM CLOCK. If for some reason
the system clock YEAR does NOT match the YEAR Parameter,
Page - 22
MSGTOSS.CFG Reference Manual
MSGTOSS will abort. This is to help prevent the
accidental deletion of messages based on the
DAYSTO/DAYSFR Parameters by a faulty system clock. Set-
ting this parameter to zero will override this check and
believe the system clock no matter how wrong it is.
Example:
YEAR-------->1991
NOTE: Reset this parameter on New Years Day!
NOTE: If zero (or blank) then MSGTOSS will assume the sys-
tem clock is fine. For safetys sake, it would be
best if you use this feature, but right around
christmas time set to zero, then sometime after new
years re-set it back.
-----------------------------------------------------------------------
FIXMSGCMD - Fix [MSGFILE] with this ([USRFILE] available)
Example:
FIXMSGCMD--->FIXMSG [MSGFILE]
When using the /FIX or /FIXC command lines, MSGTOSS will
attempt to repair a corrupt message base using this com-
mand, dynamically replacing the USER file and MESSAGES
file with [USRFILE] and [MSGFILE]. This is a Shell opera-
tion, so enough memory must be present to execute the fix-
er and return to MSGTOSS.
If you don't have FIXMSG, you can do a simple fix by sim-
ply entering:
FIXMSGCMD--->COPY C:\RBBS\BLANKM.DEF [MSGFILE]
Where C:\RBBS\BLANKM.DEF is a small, un-corrupt message
base that will be copied over the corrupt message base.
Not very practical, but will will work 100% of the time.
-----------------------------------------------------------------------
Page - 23
MSGTOSS.CFG Reference Manual
Duplicate checking related stuff (CDUP:1 keyword)
--------------------------------
DUPFILE - Created by MSGTOSS, Database of EID codes. If using
the "/WDIR" (work directory) switch while tossing, MSGTOSS
will copy it to/from the ramdisk before and after execut-
ing MSGTOSS, as long as sufficient space exists.
DUPFILE----->MSGTOSS.EID
-----------------------------------------------------------------------
MAXAREAS - Reserves so many spaces in the EID database. Max number
of conferences you would EVER have (I have 28, and mine is
set for 100, which I would never carry). Each require 32
bytes.
MAXAREAS---->100
-----------------------------------------------------------------------
DUPSIZE - The number of previous messages to keep track of in each
area of each conference. Basically, the bigger, the
slower message processing. If your message bases average
500 messages, then set to at least 500. However, numbers
over 1000 are possible. For optimum processing speed,
its best to use the /WDIR switch and make WORKDIR----> a
RAMDISK for faster processing. MSGTOSS will copy to/from
the WORKDIR automatically before/after each MSGTOSS run.
Example:
DUPSIZE----->500
NOTE: If you have a reliable HUB, who faithfully checks
for DUPS before sending to you, then the use of the
CDUP:1 keyword may NOT be necessary and will make
mail events as fast as possible.
These TWO parameters (DUPSIZE and MAXAREAS) determine
critical aspects to the MSGTTOSS.EID database. Its infor-
mation can be edited/viewed via the supplied MSGTOSS util-
ity called MSGEID.EXE. This utility allows you to change
things such as MAXAREAS & DUPSIZE, viewing the AREA Index,
displaying the number of EID codes present in each area,
etc. See MSGSWI.DOC for more information on this.
NOTE: Executing with the CDUP:1 keyword the first time
will create MSGTOSS.EID. The approximate size of
the EID database file can be estimated using the
following formula:
((8 * DUPSIZE) * NUMBER.OF.AREAS.YOU.HAVE)) + (MAXAREAS * 32)
-----------------------------------------------------------------------
Page - 24
MSGTOSS.CFG Reference Manual
Wait for users to go off-line (/WAIT switch)
-----------------------------
CONFWAIT - Number of minutes to wait till users are off line (used
with the /WAIT switch).
Example:
CONFWAIT---->10
-----------------------------------------------------------------------
Page - 25
MSGTOSS.CFG Reference Manual
Words used for message "capturing" (CAPT:1)
----------------------------------
CAPTURE - Messages that contain the TEXT entered here will be tossed
to a special area called "MSGCAPTURE". This area must be
located in your MSGTOSS.BBS file. NETMAIL, ROUTEMAIL &
UNKNOWN are exempt from capturing. The messages original
AREA:xxx tag will be tossed along with the messages.
One handy use for this feature is to prevent importing
messages that contain foul language into a BBS system, an-
other use may be to capture messages from a particular us-
er or messages that contain a particular topic.
Example:
CAPTURE----->SHIT
CAPTURE----->FUCK (We're all adults, right)
Up to 20 colorful metaphors can be defined
Whenever a message contains these words (could be anywhere
in the message) then MSGTOSS will divert those messages to
a special area defined as MSGCAPTURE. This must be en-
tered in your MSGTOSS.BBS file as a non-echo'ed area...
Example:
-CAPT:1
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300
-CAPT:0
C:\MAIL\CAPTURE.001 MSGCAPTURE
This is entered in your MSGTOSS.BBS file. Then if you
have "CAPT:1" turned on for a particular conference (in
this example the RBBS-PC conference), then those messages
will be diverted to C:\MAIL\CAPTURE.001 as a Fido-style
message. Note that you will have to create a separate di-
rectory for each unique Zone defined. After to check over
these messages, you can re-import these messages to their
respective conference via the "/TCAP" (toss captured) com-
mand line switch.
******************* WARNING WARNING **********************
* Don't use this feature to censor other BBS systems! *
* *
* This is intended to censor a private BBS system, for *
* those desiring this. A safeguard was built in to *
* prevent those who /FEED down-stream nodes from *
* capturing messages to down-stream nodes. *
**********************************************************
NOTE: To use this feature, you must turn the "CAPT:1"
switch on (in your MSGTOSS.BBS file).
NOTE: After you are done with the messages in MSGCAPTURE,
Page - 26
MSGTOSS.CFG Reference Manual
you can re-toss back to the proper area by using the
"/TCAP" (toss capture) switch.
NOTE: If using /FEED (toss to down-stream nodes while
tossing) MSGTOSS will continue to feed the nodes,
but the message will be captured "locally".
NOTE: If using /TCAP and the /FEED switch, MSGTOSS will
NOT feed "captured" messages, as they should have
already feed during the first /FEED session.
-----------------------------------------------------------------------
Page - 27
MSGTOSS.CFG Reference Manual
Strip lines beginning with "text" (SECL:1)
---------------------------------
SECL - Using these parameters will DRASTICALLY improve the num-
ber of messages allowed to be imported in a given message
base, as SEEN-BY: lines can take up incredible amounts of
space. This is usually on the order of a 30-40% in-
crease of the number of messages allowed in a given mes-
sage base.
NOTE: The use of this switch creates such an EFFICIENT
storage medium for echomail that it is sometimes
necessary to INCREASE the 'Maximum Messages'
entry on the message base 'Checkpoint Record'.
This can be accomplished by the MSGMULT----->
parameter switch. See documentation on this
parameter for more information.
These parameters are utilized ONLY when the "-SECL:1"
is activated in your MSGTOSS.BBS file. This also requires
the "-FMAS:1" switch to be active also. These entries de-
termine exactly what lines in the RBBS echomail messages
(not FIDO) are to be ignored during tossing.
Example: You want to strip all occurrences off the
"SEEN-BY:" lines in RBBS messages:
SECL-------->SEEN-BY:
Example: Most echomail control lines begin with a "" so:
SECL-------->
Will strip EID:, PATH:, MSGID: & VIA: and any other
line that begins with an .
Example: You ONLY want to strip PATH: and VIA: lines:
SECL-------->PATH:
SECL-------->VIA:
All other lines that begin with an will be imported as
normal.
NOTE: The most restrictive entry will override a similar
less restrictive entry, example:
SECL-------->
SECL-------->PATH:
The first entry ALREADY will strip the second entry!
NOTE: Up to 20 "SECL-------->" entries are possible.
-----------------------------------------------------------------------
Page - 28
MSGTOSS.CFG Reference Manual
Miscellaneous Stuff
-------------------
UTIL1 - Batch file or ?? which contains UTIL1CMD commands
-----------------------------------------------------------------------
UTIL1CMD - Miscellaneous utility command [MSGFILE], [USRFILE], [AREA]
& [WELFILE] available for processing.
Example:
UTIL1------->UTIL1.BAT
UTIL1CMD---->SUBJECT I:[MSGFILE] O:[WELFILE] C:[AREA]
And messages were received in the areas RBBS-PC & COMM
The above would create a file called UTIL1.BAT that
contains the following:
SUBJECT I:C:\RBBS\RBBSM.DEF O:C:\RBBS\RBBSW.DEF C:RBBS-PC
SUBJECT I:C:\RBBS\COMMM.DEF O:C:\RBBS\COMMW.DEF C:COMM
Which you could then execute immediately after MSGTOSS to
preform special maintenance or whatever.
NOTE: MSGTOSS will delete the UTIL1.BAT (if exist) each
time it is run, so execution MUST be done
immediately after MSGTOSS exits, or clever
batch-file renaming magic can be preformed.
-----------------------------------------------------------------------
UTIL2 - Batch file or ?? which contains UTIL2CMD commands
See UTIL1-------> details.
-----------------------------------------------------------------------
UTIL2CMD - Miscellaneous utility command [MSGFILE], [USRFILE], [AREA]
& [WELFILE] available for processing.
See UTIL1CMD----> details.
-----------------------------------------------------------------------
REGCODE - A twelve-digit registration code. Upon registration, the
author will send you this personal code (either by E-Mail
or envelope) in which MSGTOSS will recognize you as a per-
sonal supporter of MSGTOSS.
Note that MSGTOSS is not crippled in any way, and will
function with all of its features w/o the REGCODE. During
your trial period, set this code to blank (""). Don't
worry, there are NO time-bombs in MSGTOSS. Please help
support the authors efforts for this fine program. See
page two of all MSGTOSS documents for information regard-
ing registering MSGTOSS.
NOTE: Attempting to use an incorrect code will result in Page - 29
MSGTOSS locking up, and you will have to re-boot.